Thanks for updating your PR! It now meets our contributing guidelines. 👍

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found one potentially related PR:

Related PR:

• fix: OpenCode was injecting reasoningSummary for GPT-5 and forwarding it through the openai-compatible chat adapter #14783: "fix: OpenCode was injecting reasoningSummary for GPT-5 and forwarding it through the openai-compatible chat adapter"
  • fix: OpenCode was injecting reasoningSummary for GPT-5 and forwarding it through the openai-compatible chat adapter #14783
  • This PR addresses a similar issue with reasoningSummary being injected for GPT-5 in the openai-compatible provider, which is the core problem that PR fix(opencode): support responses wire mode for openai-compatible gpt-5 #16255 is fixing with an alternative approach (supporting responses wire mode).

The current PR (#16255) appears to be a refinement/alternative solution to the issue previously tackled in #14783, adding support for an optional wireApi: "responses" mode for openai-compatible providers to properly handle reasoning options.

Thanks! I know this overlaps with #14783 on the core bug fix (avoiding reasoningSummary on openai-compatible chat requests).

This PR keeps that same default fix, and additionally adds an optional responses path via provider..options.wireApi = "responses" (wire_api also supported) for providers that support /v1/responses.

If maintainers prefer the smallest possible change, I can split this and keep only the minimal bug fix in this PR (or open a follow-up for the responses-wire part). Happy to adjust to whichever merge strategy you prefer.

left a comment on the issue, also if ur on discord feel free to @ me in dev channel and we can talk faster

Thanks for the guidance. I resolved this on my side by switching responses-based custom models to model-level provider.npm: "@ai-sdk/openai" (instead of using @ai-sdk/openai-compatible for those models). I’m closing this PR to avoid overlap/noise with the ongoing generic fixes.

One request: it would really help to clarify this in docs (when to use @ai-sdk/openai vs @ai-sdk/openai-compatible, and that model-level npm override is supported).

Closing this since the issue is resolved for me via config: use model-level for responses-based custom models.\n\nDocs clarification request remains: please document when to use vs , and explicitly mention model-level npm override.

Closing note (formatted): this is resolved for me via config by using model-level provider.npm = "@ai-sdk/openai" for responses-based custom models.

Docs ask: please clarify when to use @ai-sdk/openai vs @ai-sdk/openai-compatible, and explicitly mention that model-level npm override is supported.